Within a messaging network, messages may be sent from one data processing system to other systems via one or more message brokers that handle routing and, in many cases, formatting and other services in relation to the messages. The brokers may be located at intermediate network locations between the message senders and receivers, for example running on powerful systems at communication hubs, or at various points within a distributed multi-broker network.
Many message brokers support the publish/subscribe communication paradigm. This involves publishers sending publications to a message broker, and the broker forwarding the publications to a set of subscribers who have registered their interest in receiving communications of that type. Typically, publish/subscribe brokers route publications to subscribers without the publishers needing to know which subscribers are interested. The publish/subscribe paradigm allows subscribers to receive the latest information relating to a subject area of interest (for example, stock prices or events such as news flashes or store special offers) without having to proactively and repeatedly request that information from each of the publishers.
A typical publish/subscribe environment has a number of publisher applications sending messages via a broker to a potentially large number of subscriber applications located on remote computers across a network. The subscribers register with the broker and identify the message types they wish to receive, and this information is stored at the broker. In many publish/subscribe implementations, subscribers specify one or more topic names which represent the message types they wish to receive. When publishers send their messages to the broker, the publishers assign topic names to the messages and the broker uses a matching engine to compare the topics of received messages with stored subscription information for its registered subscribers. This comparison determines to which subscribers the message should be forwarded. Topics are often specified hierarchically, for example using a character string format such as “root/topicLevel1/topicLevel2”, and topics specified within received messages are compared with subscriptions using a matching algorithm that iteratively steps through the topic hierarchy.
Although subscription matching often involves checking topic fields within message headers, the matching process may additionally or alternatively involve checking other message header fields and/or checking message content and/or filtering messages based on some additional information. For example, a message broker implementing the Java Message Service (JMS) (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both), typically allows filtering based on message properties, but not based on the application data that is the message content or “payload”. A message broker may perform additional functions, such as formatting or otherwise processing received messages before forwarding them to subscribers.
A commercially available example of a message broker product that supports the publish/subscribe paradigm is IBM Corporation's WebSphere Message Broker, as described in the documents “IBM WebSphere Message Broker Version 6 Release 0—Introduction”, IBM Corporation, July 2006, and “IBM WebSphere Message Broker Version 6 Release 0—Publish/Subscribe”, IBM Corporation, July 2006. A message broker may be associated with an underlying messaging product that handles the complexity of providing assured message delivery over a heterogeneous network. For example, IBM Corporation's WebSphere MQ messaging products provide such messaging functions, and are described in a number of publications from IBM Corporation including IBM publication reference No. GC34-6590-01 “WebSphere MQ Clients”, June 2005, (IBM and WebSphere are registered trademarks of International Business Machines Corporation).
One known publish/subscribe messaging architecture implements a publish/subscribe matching engine on the same data processing system as a subscriber application. Publishers send publications to this system (and other systems, via multicasting) and the publish/subscribe matching engine determines which publications are of interest to the local subscriber application program and should be passed to that application program. Any publications that are not of interest to the local subscriber application program are discarded, and in many cases a matching engine will discard the vast majority of received publications.
This transmission of large numbers of unwanted publications, and the processing required to discard them at each receiving system, is wasteful of communication bandwidth and of the data processing resources of the subscriber's system. Such known solutions will not satisfy the needs of many businesses for increased message throughput with high performance (scalability), despite efforts by the solution providers to design matching algorithms that efficiently discard unwanted publications.
FIG. 1 shows a known prior art messaging network 10, which comprises a plurality of message brokers 12. These brokers 12 are assumed to be connected together loosely in a network, such as internal Intranet within a business organization. The message brokers 12 together form a collective, which provide a publish/subscribe messaging network to publishers and subscribers. Each publisher and subscriber is connected to a local message broker 12. For each subscriber who subscribes to a topic for the first time, a proxy subscription 14 has to be sent out to the other brokers 12 within the network 10. For example, a subscriber at message broker “A” causes proxy subscriptions 14 to be sent out to all brokers 12 in the collective.
A proxy subscription 14 is sent by the specific message broker “A” to all of the other message brokers 12 within the network 10. If there were many subscribers and many topics then each broker 12 will end up having to hold a large number of the proxy subscriptions 14. This creates a relatively large storage requirement on each and every message broker 12. In addition, every time a subscriber unsubscribes from a topic, then a message has to be sent to each message broker to cancel the proxy subscription 14.
In the prior art system, every time a subscriber subscribes to a new topic, then a proxy subscription 14 is transferred to all of the brokers 12 in the network 10. When a publisher that is connected to the message broker “B” (shown in FIG. 2), publishes a message to the same topic, then that broker 12 already has a proxy subscription 14 for the subscriber connected to the node “A”, so a message 16 is delivered directly to the subscriber's broker 12. The broker “A” formats that message 14 in a conventional manner and transmits it onwards to all of the subscribes connected to the node “A” that are subscribed to the relevant topic.